An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

Hello everyone, I am currently developing a smart camera app for iOS that recommends optimal zoom and exposure values on-device using a custom Core ML model. I am still waiting for an official response from Apple Support, but I wanted to ask the community if anyone has experience with a similar workflow regarding App Review and the DPLA. Here is my training methodology: I gathered my own proprietary dataset of original landscape photos. I generated multiple variants of these photos with different zoom and exposure settings offline on my Mac. I used the CalculateImageAestheticsScoresRequest (Vision framework) via a local macOS command-line tool to evaluate and score each variant. Based on those scores, I labeled the "best" zoom and exposure parameters for each original photo. I used this labeled dataset to train my own independent neural network using PyTorch, and then converted it to a Core ML model to ship inside my app. Since the app uses my own custom model on-device and does not send any user data to a server, the privacy aspect is clear. However, I am curious if using the output of Apple's Vision API strictly offline to label my own dataset could be interpreted as "reverse engineering" or a violation of the Developer Program License Agreement (DPLA). Has anyone successfully shipped an app using a similar knowledge distillation or automated dataset labeling approach with Apple's APIs? Did you face any pushback during App Review? Any insights or shared experiences would be greatly appreciated!

I’m trying to find out whether anyone has seen this kind of App Store Connect issue remain unresolved for this long. This is for a first auto-renewable subscription. Timeline: Original support case opened: Feb 27, 2026 Support initially repeated the normal guidance that the first subscription must be submitted with the app version I explained that the issue was not the process itself, but a stuck review state On Mar 25, 2026, I was told the case had been escalated to the appropriate internal team Since then, I have sent follow-up emails asking for status / owner / ETA As of Apr 12, 2026 (KST), there has still been no meaningful update Current state in App Store Connect: App version 1.0.10 is still “Prepare for Submission” Previous 1.0.10 submissions show as “Deleted” There is no active app review submission for 1.0.10 The subscription previously showed “Waiting for Review” Now the subscription itself shows “In Review” But its localization still shows “Waiting for Review” So the state looks inconsistent: no active app review submission app version still draft subscription partially moved into review anyway At this point I’m not asking about the normal first-subscription submission flow. I already understand that. What I’m trying to understand is: Has anyone seen a case like this stay stuck for 6+ weeks? Has anyone had Apple say it was escalated internally and then go silent for weeks? Did Apple eventually fix it manually? Is this something that can remain stuck indefinitely unless the internal team intervenes? Any comparable experience would be helpful.

Hello, I would like to request an escalation regarding my app review status. My app (Apple ID: 6758756966) was submitted for review on February 24 and has been in “Waiting for Review” status for an extended period, with no progress so far. I have contacted Apple Developer Support multiple times (Case IDs: 102840237455, 102840079647, 102846664998, 102841727941) starting from March 9, but unfortunately, I have not received any response to any of these requests. I have also submitted three expedited review requests, but none of them have been acknowledged. Could you please: • confirm whether the submission is still active in the queue • check if there are any issues preventing it from moving forward • and assist in escalating the review if possible If any additional information is required from my side, I am ready to provide it immediately. Thank you very much for your time and support.

Hello, Our application has been stuck in the "In Review" status for 17 days now, and we are looking for guidance on whether this is a known technical stall or an extended policy audit. The Issue: The app moved from "Waiting for Review" to "In Review" on March 25th. Since then, there has been no change in status and no messages in the Resolution Center. App ID: 6753868146 Thanks

Apple review usually takes a couple hours or even 2 days or less to review my submissions but it’s taking them 4 days to review it I submitted on a Wednesday. should I re-submit?

Hello Apple Developer Community and App Review Team, I'm writing to seek guidance regarding my app Lookify: AI Virtual Try-On (App ID: 6757718224), which has been caught in an ongoing review cycle since February 15, 2026 — nearly two months ago. Submission History: Date Version Status Feb 15 iOS 1.1.0 Removed Feb 19 iOS 1.1.0 Removed Feb 21 iOS 1.1.0 Removed Apr 3 (2:21 AM) iOS 1.1.0 Removed Apr 3 (1:17 PM) iOS 1.1.0 Removed Apr 6 (current) iOS 1.1.0 Waiting for Review Each submission was either self-removed after extended waiting periods with no reviewer feedback, or removed to address potential issues — only to re-enter the queue with the same outcome. The current submission has now been in "Waiting for Review" status since April 6 with no activity, no messages, and no indication of progress. What I've done to comply: Updated the Privacy Policy to be fully GDPR and KVKK compliant Provided clear demo account credentials and usage instructions for the AI try-on feature Ensured all metadata, screenshots, and descriptions accurately reflect the app's functionality Reviewed Apple's App Review Guidelines thoroughly before each resubmission I understand that AI-powered apps — especially those involving visual try-on technology — may require closer scrutiny, and I fully respect that process. I'm not asking to bypass any review step. I simply ask for transparency: if there is an issue with the app, a rejection with specific feedback would allow me to address it immediately. This app represents months of development work. As a small independent developer, prolonged uncertainty without communication makes it very difficult to plan or improve. My request: Could anyone from the App Review team or community provide insight into: Whether there is an active flag or concern on this submission What the expected timeline might be for accounts with this submission history Whether an Expedited Review would be appropriate given this timeline I have also submitted a contact request through the official App Review contact form. I am fully committed to making any necessary changes — I just need to know what they are. Thank you sincerely for your time and assistance. Mustafa Bilgiç Developer, PlayTools

ID 6758008521, Dear App Review Team, I submitted my app review and it got rejected for inaccurate screenshot. I have revised the app screenshot and also resubmitted. But it has been 8 days and no response. We look forward to completing the review, thank you.

Hola, el día 20 de enero de 2021 a las 7:26 p. m. hice la compra del programa para desarrolladores y Apple quedo de enviarme un correo cuando todo este listo, ya han pasado las 42 horas y no tengo respuestas, ya le escribí a soporte espero me ayuden. De igual manera quisiera saber cuanto tiempo les demoro a ustedes todo el proceso de compra y verificación, espero me ayuden. Gracias

Hi everyone, I’m looking for advice on a repeated App Store rejection under Guideline 2.5.1. Background: We initially explored using Family Controls for a planned feature. That feature has now been fully removed from the app. We no longer provide any Screen Time related functionality. What we already cleaned up: Removed all FamilyControls / ManagedSettings / DeviceActivity code usage. Removed commented-out code and all related references from the project. Removed related capabilities and entitlements from targets. Removed related frameworks/dependencies. Performed a clean rebuild and submitted a new archive. However, App Review still says the app includes ScreenTime API in an unapproved manner and suggests removing those APIs. Questions: What are the most common hidden places where Screen Time / Family Controls traces remain? Has anyone seen this triggered by transitive dependencies or stale build artifacts? What evidence/details should I provide in App Review Notes to help the reviewer verify cleanup? Is there a recommended way to ask App Review to share the specific symbol/framework/target they detected? Any practical checklist or experience would be greatly appreciated. Thank you.

We recently ran into an issue where our submission was rejected due to references to an API that we are not using but that was present in the code. Guideline 2.5.1 - Performance - Software Requirements Issue Description The app uses the Clinical Health Records API but the app does not appear to include any primary features that require the Clinical Health Records API. Next Steps To resolve this issue, please remove the Clinical Health Records API from the app, as well as any references to this app’s interactivity with Clinical Health Records from the app or its metadata. And as it turns out, we actually did have references to that API that we had missed and did have to remove them. Usually, I would recommend to just resubmit the new build and see if it gets accepted, then hold it until the powers that be approve it for publication. For this client, though, their QA team forces us into more of a waterfall-ish approach, where we are not allowed to submit production builds ahead of time (i.e. until after all manual testing has concluded, test evidence has been filed and the required documents have been updated and approved). And if after resubmission we find something else that needs to be fixed, we get to restart the process all over again. That's ... slower. We do have a workaround in place where we submit a development build for review and check whether that would get accepted, then retract that version and submit the production build once we are allowed to. But that means more work for Apple (the App has to be reviewed twice) and more risk for us (if the submission team accidentally publishes a development build, the consequences would be severe). Is there a tool that allows us to check for guideline violations without having to submit a build to the App Store Connect? I'm not looking for a "yes, this will get approved" kind of guarantee, just a "well, the review team may find something else to question / reject, but as far as automated checks go, this looks ready for submission".

Hello, I submitted my app for review and it was rejected under Guideline 4.2. I believe the rejection was a misunderstanding of my app's functionality, so I filed an appeal through the Resolution Center explaining why I believe my app meets the minimum functionality requirements. It's been passed almost two weeks since I filed the appeal but I've received no response or update on the status. My app is directly tied to an event launching next week, and without a resolution, I will miss the launch window entirely. I'd greatly appreciate any visibility into where my appeal stands, or any guidance on what steps I can take to move this forward. Thank you for your time.

I’ve had an issue with all of my apps. Where I push my build to TestFlight and then the image pops up. I’ve troubleshooted EVERYTHING. My account has no issues on it, no payment or compliance issues. I’ve looked to reddit for advice, one user says they need there app to get approved by apple, i got a couple apps to have there update approve, still the bug persist. Whether the app is on the App Store or a work in progress nothing works.

I submitted an app build and filled out the expedited review form, they quickly replied: “The issues we've identified below are eligible to be resolved on your next update. If this submission includes bug fixes and you'd like to have it approved at this time, reply to this message and let us know. You do not need to resubmit your app for us to proceed.” I replied with “Yes, please accept the current version now as it contains bug fixes, will resolve that issue later lalala” I replied again 1 day after the letter. And nothing. 2 days total have passed. So the replies do not go to the Expedited Review queue? What should I do? Reply again? Or resubmit the build with a comment “Important bug fixes, please accept immediately”? Or maybe call them, will a call help? Thank you so much!

New member here, please be gentle :) I am getting ready for App Review for my first iOS app, and I am curious if ANY level of obfuscation is allowed? Say I had a drone controller App, I might have something like this: struct Drone{ var name : String var forwardVelocity : Double var lateralVelocity : Double var verticalVelocity : Double var receivedSignalStrength : Int var rssThreshhold : Int var gpsCoordinates : Data func reverseCourse(){ //do a 180 //... } } func onUpdateReceivedSignalStength(drone:Drone){ if drone.receivedSignalStrength < drone.rssThreshhold{ drone.reverseCourse() } } But I don't really want to make it easy for someone to pull the strings from the binaries and try and copy my work. I realize it's pretty much inevitable, but it seems sensible to protect my IP as much as I can. Is something like this acceptable? struct D{ //obfuscated Drone var parameter1 : String //name var parameter2 : Double //forwardVelocity var parameter3 : Double //lateralVelocity var parameter4 : Double //verticalVelocity var parameter5 : Int //receivedSignalStength var parameter6 : Int //rssThreshhold var parameter7 : Data //gpsCoordinates func funcSeven(){ //do a 180 //... } } func funcSix(d:D){ //check if signal strength requires a course reversal if d.parameter5 < d.parameter6{ // signal strength less than threshhold d.funcSeven() //reverse course } } The comments make it clear what the similarly-named parameters are doing, and what the functions do. I fully understand that something like the below is a no-no, just writing it made my eyes bleed: struct DDF{ var SXR : String var KYV : Double var GTC : Double var DKY : Double var ENY : Int var WKN : Int var DJV : Data func BDO(){ //do a 180 //... } } func PUL(KHY:DDF){ if KHY.ENY < KHY.WKN{ KHY.BDO() } } Is there any level of IP protection through obscurity that is acceptable? I realize that the more genericized the variable and function names are, the harder it is to debug, but that might be an acceptable trade-off against IP protection. To be clear, my app isn't anything to do with drones, this was just a vehicle to ask the question with. My code isn't currently at all obfuscated, everything is in clear terms, but I am wondering if I could/should obfuscate the critical parts before App Review and release? The reason for my concern is that a key feature of the app is something very novel, and I have filed a patent application for it. The patent (if granted) won't be granted for 18-24 months, so anything I can do to protect the IP seems like the right thing to do. As a complete newcomer to releasing Apps, I have no experience at all, so I would be grateful for any help/steers from those that do have experience in trying to protect their IP while not making life difficult for the App Review team. Thanks in advance! 6502A

I need to bring attention to a very suspicious "copycat" incident that suggests a potential metadata scraping issue. I submitted my original sports insights app, KickPick, for review on April 2nd, 2024. To my shock, I discovered a competitor app already live on the store with same app name and nearly identical app information (descriptions, metadata) and a very similar UI structure. Domain Registration: The infringing developer registered their website domain on the exact same day I submitted my app for review (April 2nd). This is not a coincidence; it points to automated monitoring or scraping of new submissions/metadata. Plagiarized Legal Assets: While the UI has some variations, they have copied my Privacy Policy and Terms of Service verbatim. These documents were custom-written for my specific project logic, yet they appear on their site with only the company name changed. App Information: The app descriptions and store metadata are almost identical to what I provided in my pending submission. It is highly concerning that an original creator's work, is being "front-run" by a low-effort clone that appears on the store exactly when the original is submitted. I have filed a formal Rights Infringement report, but I want to ask the community: Has anyone else noticed clones popping up with domains registered on their exact submission date?

My game's critical update (related to AdMob) has been stuck in the review queue for over 2 months now. I’m not exaggerating - it’s literally been more than 2 months. I’ve never experienced anything like this before. My updates used to get approved within 2–3 business days at most. But this time, the process seems completely broken. The update was sitting in the queue since February 4th and wasn’t even taken into review. I finally gave up and rejected it myself on April 4th, then resubmitted it. It’s still the same story: stuck in the queue with zero progress. During this time, I’ve sent multiple emails and messages. None of them provided any useful information, and now I’m basically being ghosted by support. Thanks, Apple, for the amazing support and the value you give to developers. Bonus: Another one of my games has been waiting for its initial release for 15 days now. At this rate, I guess I should expect 3–4 months for that one too. The worst part isn’t just the delay - it’s the complete lack of any meaningful explanation.

Context: We are developing an SDK to support global age verification regulations (e.g., Texas HB 18, Brazil’s LGPD). We plan to use the DeclaredAgeRange and PermissionKit frameworks. We want to verify if our proposed "Block-by-Default" sequence for non-compliant states is legally and policy-compliant according to Apple’s standards. Detailed Workflow Description: Initial Authentication: After the user logs in, the SDK calls requestAgeRange(ageGates: 13, 16, 18). Handling Sharing Status: If Declined: If the user declines age sharing (.declinedSharing), the SDK blocks app access and displays a popup guiding them to enable sharing in System Settings. Age Verification Results: Adult (VERIFIED, 18+): Immediate access to the game. Non-Regulated Region (UNKNOWN): Access to the game is allowed. Minor (SUPERVISED, 13-17): Step A (Age Gate): We check if they are 13+. If they are under 13, we block access and show an "Underage" notice. Step B (Family Sharing): If they are 13+, we check if Family Sharing is linked. If NOT linked, we block access and show a guide to set up Family Sharing. Significant Update & Parental Consent: If a "Significant App Update" requires consent (via requiredRegulatoryFeatures), we call AskCenter.shared.ask with a SignificantAppUpdateTopic. If Approved: The minor is allowed to proceed to the game. If Denied/Pending: Access is blocked, and a "Parental Consent Required" notice is displayed. Information Unavailable (REQUIRED): If age info cannot be verified, access is blocked with a guide on how to provide age information. Specific Questions for Feedback: Blocking for Non-Consent: In regions where Age Assurance is legally required, is it acceptable under App Store Review Guidelines to block app functionality for users who choose .declinedSharing? Mandatory Family Sharing: Is it permissible to require Family Sharing for 13-17-year-old minors to access the app, or must we provide alternative parental verification methods (e.g., credit card verification) for those not using Family Sharing? VPC Compliance: Does using SignificantAppUpdateTopic via AskCenter satisfy the "Verifiable Parental Consent (VPC)" requirements for regulations like Texas HB 18 or Brazil's LGPD for initial gameplay access? User Experience (UX): Does this "Strict Blocking" approach for unverified or non-consented states violate any policies regarding "App Functionality" or "Data Privacy," even if implemented for legal compliance?

Hi everyone, I’m dealing with a strange App Review delay and would appreciate any advice from people who faced something similar. My app was released on January 20. A small update was approved quickly on January 28, and another one on January 29. So far everything looked normal. Then I submitted another update on February 6. This submission stayed in “Waiting for Review” for 3 weeks with no progress. During that time, I contacted Apple Support to ask if something was wrong with my submission or the review queue. The response took quite a while, and since nothing was changing, I assumed the queue got stuck. So I decided to remove the update and resubmit it. Later Support replied and told me that I removed my own update, and that the queue was working normally and there was nothing I needed to do. However, even after resubmitting, the new build stayed in the same “Waiting for Review” status all the way until March 19 — with no signs of movement. At this point I started to think maybe the review team found some critical issues that would block the app from going live. I rechecked the entire app, didn’t find anything serious, but fixed a couple of small bugs and submitted another update. Unfortunately, this update is now also stuck in “Waiting for Review.” Additionally, I requested an expedited review on April 6, but haven’t received any response or changes in status. So at this point I’m not sure what else I can do. Has anyone experienced something similar? Is there anything that helped you unblock a submission stuck in this state? Any advice or shared experiences would be greatly appreciated.

Hi everyone, I uploaded my first app over a month ago now and there has been no status change at all. I have been stuck in ‘waiting for review’ the whole time since upload. I know Apple say sometimes it may take over the 24-48 hours but 1 month seems like I’ve been missed out. I’ve also submitted an expedited review to see if that helps but nothing as of yet. Does anyone have any advice at all? Thanks.